IPTV solutions of today suffer from long channel switching times, that is, it takes a long time from the moment an end user initiate a channel change on the remote unit until sound and picture of the selected channel is present on the TV screen. There are many sources to this delay, but the main source is the encoding techniques used to get a balance between picture quality and the bandwidth required.
The most commonly used encoding techniques are MPEG2 and MPEG4. Both of these techniques use an encoding scheme where the encoder at regular intervals sends a complete picture called an I-frame and in between these I-frames it sends two types, called B- and P-frames, of incomplete pictures describing how the picture changes over time relative to the I-frame. The P and B frames cannot be decoded without the corresponding I-frame. As I-frames contain a lot of information requiring a lot of bandwidth to send, a longer interval between I-frames gives a lower overall bandwidth requirement. However, the decoder in the TV or set-top box cannot start decoding until it receives an I-frame, thus increased I-frame interval (called GOP-length (Group of Picture length)) results in a longer average decoding delay. Statistically this delay will be on average a half of the GOP-length. The encoded content is usually sent as a multicast stream allowing many users to share the same stream thereby saving bandwidth in the access network.
In prior art solutions, e.g. as described in US 2005/0081244 A1, the delay is decreased by creating a buffering node, called VQE (Video Quality Experience) server. This VQE server acquires packets from all available multicast channels and maintains separate cyclic buffers for each channel, holding all packets from the last N seconds. The buffered channels always start with an I-frame. Upon a channel change request, a unicast stream will be sent to the client out of that buffer of the VQE server containing appropriate metadata and an I-frame of the requested channel. As soon as the decoder in the client receives the I-frame in the unicast stream from the buffer of the VQE server it will start buffering and decoding the content. Since the channels are buffered in the VQE server, the timing of the channels is behind the timing of the regular multicast streams. Hence, this unicast stream will be sent to the client until the unicast stream has caught up with the regular multicast stream. When the unicast stream has caught up with the regular multicast stream, the client will terminate the unicast connection and start receiving content from the regular multicast stream.
The major problem with the prior art solutions is the lack of scalability in bandwidth and served requests per second. As each client request leads to one unicast stream sent from the VQE server, the number of simultaneous requests that can be served is severely limited by the available bandwidth in the access network, with the main bottleneck being the available bandwidth on the outgoing port of the VQE server.
Another related issue with the solution above is the lack of graceful degradation, that is, in high load conditions new requests will be denied resulting in that no fast channel change will be provided giving a really poor end user experience. One possible way to fix this is to add more hardware, for example, by adding more VQE servers. Unfortunately this solution is not always affordable.